A storage system typically comprises one or more storage devices into which information may be entered, and from which information may be obtained, as desired. The storage system includes an operating system that functionally organizes the system by, inter alia, invoking storage operations in support of a storage service implemented by the system. The storage system generally provides its storage services through the execution of software modules, such as processes. The storage system may be implemented in accordance with a variety of storage architectures including, but not limited to, a network-attached storage environment, a storage area network and a disk assembly directly attached to a client or host computer. The storage devices are typically disk drives organized as a disk array, wherein the term “disk” commonly describes a self-contained rotating magnetic media storage device. The term disk in this context is synonymous with hard disk drive (HDD) or direct access storage device (DASD).
The storage system may be further configured to operate according to a client/server model of information delivery to thereby allow many clients to access information stored on the system. In this model, the storage system may be embodied as file server executing an operating system, such as the Microsoft® Windows™ operating system (hereinafter “Windows operating system”). Furthermore, the client may comprise an application executing on an operating system of a computer that “connects” to the server over a computer network, such as a point-to-point link, shared local area network, wide area network, or virtual private network implemented over a public network, such as the Internet. Each client may request the services of the server by issuing storage access protocol messages (in the form of packets) to the server over the network. By supporting a plurality of storage (e.g., file-based) access protocols, such as the conventional Common Internet File System (CIFS) and the Network File System (NFS) protocols, the utility of the server is enhanced.
To facilitate client access to the information stored on the server, the Windows is operating system typically exports units of storage, e.g., (CIFS) shares. As used herein, a share is equivalent to a mount point or shared storage resource, such as a folder or directory that stores information about files or other directories served by the file server. A Windows client may access information in the directory by mounting the share and issuing a CIFS protocol access request that specifies a uniform naming convention (UNC) path to the share. The UNC path or pathname is an aspect of a Windows networking environment that defines a way for a client to refer to a unit of storage on a server. The UNC pathname is prefixed with the string \\ to indicate resource names on a network. For example, a UNC pathname may comprise a server name, a share (directory) name and a path descriptor that collectively reference a unit of storage or share. Thus, in order to access the share, the client typically requires knowledge of the specific physical location (i.e., the identity) of the server exporting the share.
Instead of requiring the client to provide the specific identity of the file server exporting the share, it is desirable to only require a logical pathname to the share. That is, it is desirable to provide the client with a globally unique pathname to the share without reference to the file server. The conventional Distributed File System (DFS) namespace service provides such a solution in a Windows environment through the creation of a namespace that removes the specificity of server identity. DFS is well-known and described in DCE 1.2.2 DFS Administration Guide and Reference, 1997, which is hereby incorporated by reference. As used herein, a namespace is a view of shared storage resources (such as shares) from the perspective of a client. The DFS namespace service is generally implemented using one or more DFS servers and distributed components in a network.
Using the DFS service, it is possible to create a unique pathname (in the form of a UNC pathname) for a storage resource that a DFS server translates to an actual location of the resource (share) in the network. However, in addition to the DFS namespace provided by the Windows operating system, there are many other namespace services provided by various operating system platforms, including the NFS namespace provided by the conventional Unix® operating system. Each service constructs a namespace to facilitate management of information using a layer of indirection between a file server and client accessing a shared storage resource (share) on the server. For example, a share may be connected or “linked” to a link point (link in DFS terminology or a mount point in NFS terminology) to hide the machine specific reference to the share. By referencing the link point, the client can automatically access information on the storage resource of the specific machine. This allows an administrator (user) to store the information on any server in the network by merely providing a reference to the information (or share). However, these namespaces are typically services created on heterogeneous server platforms, which leads to incompatibility and non-interoperability with respect to management of the namespaces by the user. For example, the DFS namespace service is generally limited to Windows-based operating system platforms, whereas the NFS namespace service is generally limited to Unix-based operating system platforms.
The Virtual File Manager (VFM™) developed by NuView, Inc. and available from Network Appliance, Inc., (“NetApp”) provides a namespace service that supports various protocols operating on various file server platforms, such as NetApp filers and DFS servers. The VFM namespace service is well-known and described in VFW™ (Virtual File Manager) Reference Guide, Version 4.0, 2001-2003, and VFM™ (Virtual File Manager) Getting Started Guide, Version 4.0, 2001-2003.
A difficult and time-consuming issue involved with managing a server, such as a file server or filer, is copying data, e.g., a data set, from an original server (“primary server”) to another server (“backup server”) to protect against data loss/corruption due to primary server failure. As used herein, a data set is defined as one or more storage units, such as volumes and/or “qtrees” that when combined represent data being protected against disaster. A qtree is a special directory that has the properties of a logical sub-volume within a physical volume.
One way to copy or duplicate a data set onto a backup server to ensure against total primary server failure is to replicate a primary server data set at the backup server using conventional data replication facilities, such as remote asynchronous mirroring. In this sense, the duplicated data set could include all or part of a file system. An example of an asynchronous data replication facility is the SnapMirror facility available from Network Appliance, Inc. Examples of techniques for duplicating all or part of a file system that may be advantageously used with the invention are described in U.S. patent application Ser. Nos. 09/127,497 titled File System Image Transfer, by Kleiman et al, filed Jul. 31, 1998 and issued on Aug. 5, 2003 as U.S. Pat. Nos. 6,604,118 and 09/426,409 titled File System Image Transfer Between Dissimilar File Systems, by Kleiman et al., filed Oct. 25, 1999 and issued on Jun. 3, 2003 as U.S. Pat. No. 6,574,591, which applications are hereby incorporated by reference as though fully set forth herein.
Broadly stated, the SnapMirror facility periodically replicates a data set stored on a primary server (“source filer”) to a backup server (“destination filer”) at a user-definable time interval, with the range being from one minute to one month. At the end of each data replication event, the backup data set becomes an exact block-for-block “mirror” copy of the primary data set. At that point, the two data sets share identical data content and characteristics. The mirror is initialized by effectively copying the entire primary data set to the backup data set. Once this initial copy is complete, replication events thereafter copy only changed blocks from the primary data set to the backup data set to thereby provide an efficient data replication mechanism.
It is also possible to protect a unit of storage, such as share, on a primary data set that is exported by a namespace (which is used to access the share) using the data replication facility. Often, there is more than one location (link) within the namespace where the share may reside. Once the share is protected and in response to a source filer failure, another mechanism is needed to specify actions to be taken to failover the link to the backup data set on the destination filer. Such a mechanism may include a management application that detects a failure on the source filer and invokes the mirror on the destination filer.
Previous namespace services (such as the VFM namespace service) have the capability to monitor a source share on a source volume and/or qtree of a source filer and, upon a failure, insert a destination share on the mirror of the destination filer into a namespace. However, such services monitor failures at the filer level. A noted disadvantage of this approach is that if the original volume is taken offline or otherwise fails on the source filer, the services do not detect that a failure to the source share has occurred and the management application cannot invoke the mirror to access the destination share. Accordingly, applications requiring access to the destination share fail. In addition, it is possible for the source filer (and source volume) to be operational, but the source share to be inaccessible. For example, the source share may be deleted or its properties changed so that it is no longer accessible. Since the previous services cannot detect such a source share failure, the insertion of the destination share into the namespace does not occur.